大家好！歡迎來到鐵人賽第十五天。

在昨天的實作中，我們成功串接了 CIRCL CVE API，讓 n8n 能夠根據收到的資安告警，自動查詢外部漏洞資料庫，取得對應的 CVE 漏洞資訊。

不過，當我們把這些情報直接推播到 LINE 時，卻發現了一個問題：原始漏洞描述通常是冗長的英文技術文件，對於需要快速掌握風險的維運人員來說，閱讀起來並不方便。

尤其當系統在深夜發出告警時，如果還需要花時間翻譯英文、理解技術名詞，再判斷漏洞可能造成的影響，就會增加處理告警的時間。

因此，今天我們要進一步導入 AI，讓系統不只能查詢漏洞情報，還能自動整理內容，產生容易理解的繁體中文摘要。

這也是 RAG（Retrieval-Augmented Generation，檢索增強生成）架構中的最後一個階段：Generation（生成）。

今天的目標，就是讓 AI 成為系統中的資安情報助理，協助我們將查詢到的漏洞資料轉換成精簡、易讀的中文摘要，再透過 LINE 推播給使用者。

一、取得 AI 模型的 API Key

要讓 n8n 具備 AI 分析能力，我們需要先取得 AI 模型的 API Key。

這次以 OpenAI API 為例，示範如何建立金鑰並串接至 n8n。

步驟 1：建立 API Key

1. 登入 OpenAI Developer Platform。
2. 進入 API Keys 頁面。
3. 點擊 Create new secret key，建立新的 API 金鑰。
4. 複製產生的金鑰，並妥善保存。
   

API Key 是存取模型服務的重要憑證，請勿直接公開在文章、GitHub 儲存庫或其他公開環境中。

💡 實務小知識：

除了 OpenAI，也可以考慮使用其他提供 API 的模型服務，例如 Google Gemini 或 Groq。實際可用的模型、免費額度與申請條件，則需要依照各平台的規定確認。

二、在 n8n 中加入 AI 節點

取得 API Key 後，就可以回到 n8n，將 AI 模型整合進原本的漏洞情報處理流程。

原本的流程是：

HTTP Request（CVE 查詢）→ HTTP Request（LINE 推播）

現在，我們要在兩者之間加入 AI 節點，讓系統先整理漏洞情報，再將結果傳送至 LINE。

步驟 1：新增 OpenAI 節點

1. 回到 n8n 工作流程畫布。
2. 在 CVE 查詢節點與 LINE 推播節點之間新增一個 OpenAI 節點。
3. 根據目前使用的 n8n 版本，選擇文字生成或聊天模型相關的操作。
   

步驟 2：設定 API 憑證

1. 開啟 OpenAI 節點的設定面板。
2. 在 Credential to connect with 中新增憑證。
3. 將剛剛取得的 API Key 填入對應欄位。
4. 儲存憑證，確認節點能夠正常連接模型服務。

完成後，n8n 就具備了呼叫 AI 模型的能力。

三、撰寫 Prompt，讓 AI 自動整理漏洞情報

接下來是今天最重要的部分：如何讓 AI 根據實際查詢到的漏洞資料，產生符合需求的摘要？

如果直接要求 AI 解釋某個 CVE 編號，模型可能會根據既有知識生成內容，甚至產生與實際漏洞不符的資訊。

因此，我們要將昨天從 CIRCL CVE API 取得的漏洞描述，直接傳遞給 AI，讓它根據提供的資料進行整理。

這就是 RAG 架構中「檢索」與「生成」的結合。

步驟 1：設定提示詞

在 OpenAI 節點的 Messages 區塊中新增一則訊息，並將 Role 設定為 User。

接著，在 Content 欄位切換至 Expression，輸入以下提示詞：

你是一位專業的資安維運工程師。

請閱讀以下 CVE 漏洞原始情報，並以繁體中文整理出一段簡明扼要的摘要。

請遵守以下要求：
1. 摘要控制在 100 字以內。
2. 說明漏洞的主要影響。
3. 使用一般工程師容易理解的語言。
4. 僅根據提供的原始情報進行整理，不得自行推測或捏造資訊。
5. 如果原始資料不足以判斷漏洞影響，請明確說明。

【原始情報】：
{{ $json.containers.cna.descriptions[0].value }}

這段提示詞的目的，是讓 AI 將原本冗長的英文漏洞描述轉換成簡潔的中文摘要，同時降低模型自行補充未經確認資訊的風險。

步驟 2：執行 AI 節點

設定完成後，點擊 Execute step。

如果資料格式與模型設定正確，右側的 OUTPUT 就會顯示 AI 生成的摘要。

例如，原本的英文漏洞描述經過 AI 整理後，就能轉換成更容易閱讀的中文內容。

需要注意的是，AI 產生的摘要仍然需要經過驗證，不能直接將模型的輸出視為已確認的漏洞分析結論。

四、修改 LINE 推播節點，傳送 AI 摘要

當 AI 已經成功產生中文摘要後，下一步就是將結果整合進原本的 LINE 推播訊息。

步驟 1：修改 LINE 節點的訊息內容

開啟原本的 HTTP Request（LINE 推播）節點，找到傳送訊息的 JSON Body。

原本我們使用的是 CVE API 回傳的英文描述：

{{ $json.containers.cna.descriptions[0].value }}

現在，則要將它替換成 AI 節點輸出的摘要內容。

如果使用的是會將生成文字放在 message.content 欄位的節點，可以使用：

{{ $json.message.content }}

不過，實際的輸出欄位會依照 n8n 節點類型與版本而有所不同，請先確認 AI 節點的 OUTPUT，再設定正確的 Expression。

步驟 2：調整 LINE 推播格式

以下是修改後的 JSON 範例：

{
  "to": "你的_User_ID",
  "messages": [
    {
      "type": "text",
      "text": "🚨【資安系統告警】🚨\n\n受害主機：Ubuntu-Web-01\n漏洞編號：CVE-2023-38325\n受害套件：curl\n\n【AI 漏洞摘要】\n{{ $json.message.content }}"
    }
  ]
}

這樣一來，LINE 訊息就能同時呈現主機資訊、漏洞編號、受害套件，以及 AI 產生的中文摘要。

💡 注意：

經過 HTTP Request 與 AI 節點後，資料的結構可能會改變，原本 Webhook 中的主機名稱、漏洞編號等欄位不一定還能直接使用。

如果需要保留前面節點的資料，可以透過 n8n 的節點引用或 Edit Fields 等方式，將必要欄位重新整合，再傳遞給 LINE 推播節點。

五、端對端測試：從漏洞告警到中文摘要

完成所有設定後，就可以開始測試整個工作流程。

預期流程

Wazuh 偵測資安告警
        ↓
FastAPI 接收並解析告警
        ↓
n8n 接收 Webhook 資料
        ↓
HTTP Request 查詢 CIRCL CVE API
        ↓
OpenAI 節點整理漏洞情報
        ↓
HTTP Request 傳送 LINE 訊息
        ↓
收到繁體中文漏洞摘要

執行工作流程後，可以依序確認以下項目：

1. FastAPI 是否成功接收並傳遞告警資料。
2. CIRCL CVE API 是否正確回傳漏洞資訊。
3. AI 節點是否成功取得原始漏洞描述並產生摘要。
4. LINE 推播節點是否正確取得 AI 輸出。
5. LINE 是否成功收到包含漏洞資訊與中文摘要的訊息。

如果某個節點發生錯誤，可以先查看該節點的 INPUT 與 OUTPUT，確認資料是否正確傳遞。

當整個流程成功運作時，我們就完成了從漏洞情報檢索到 AI 自動摘要，再到 LINE 通知的整合。

連線成功畫面：

六、今日總結：讓資安告警更容易理解

今天，我們在原本的漏洞情報查詢流程中加入了 AI 節點，完成了 RAG 架構中生成階段的初步實作。

回顧這幾天的進度：

• 第十三天： 建立 n8n 工作流程，串接告警資料與 LINE 通知。
• 第十四天： 串接 CIRCL CVE API，讓系統能夠查詢漏洞情報。
• 第十五天： 導入 AI 節點，將查詢到的漏洞描述整理成繁體中文摘要。

透過這次的整合，系統不再只是單純傳送原始告警，而是能夠進一步整理漏洞資訊，讓維運人員更快掌握告警內容。

不過，目前 AI 的工作仍然以情報整理為主，尚未真正判斷漏洞是否適用於受害主機，也沒有執行任何自動修補操作。

那麼，當系統取得漏洞情報並完成初步摘要後，能不能進一步判斷漏洞的風險，並根據不同情況採取適當的處置？

明天，我們將繼續探索自動化資安維運的下一個階段，嘗試將漏洞情報與自動化處置流程結合，逐步建立更完整的 SOAR 工作流程。

我們明天見！

小提醒： 這篇文章中的節點名稱與輸出欄位，需要依照你實際使用的 n8n 版本確認，尤其是 OpenAI 節點的輸出格式。這樣讀者跟著操作時，才不會因為欄位不同而卡住。